The present invention relates generally to computer networks, and more specifically, to a method and apparatus for storing policies for policy-based management of quality of service treatments of network data traffic flows.
A computer network typically comprises a plurality of interconnected entities that transmit (xe2x80x9csourcexe2x80x9d) or receive (xe2x80x9csinkxe2x80x9d) data frames. A common type of computer network is a local area network (xe2x80x9cLANxe2x80x9d) that generally comprises a privately owned network within a single building or campus. LANs employ a data communication protocol (LAN standard) such as Ethernet, FDDI, or Token Ring, that defines the functions performed by the data link and physical layers of a communications architecture (i.e., a protocol stack), such as the Open Systems Interconnection (OSI) Reference Model. In many instances, multiple LANs may be interconnected by point-to-point links, microwave transceivers, satellite hookups, etc., to form a wide area network (xe2x80x9cWANxe2x80x9d), metropolitan area network (xe2x80x9cMANxe2x80x9d) or Intranet. These internetworks may be coupled through one or more gateways to the global, packet-switched internetworks knows as Internet.
Each network entity preferably includes network communication software, which may operate in accordance with Transport Control Protocol/Internet Protocol (TCP/IP). TCP/IP generally consists of a set of rules defining how entities interact with each other. In particular, TCP/IP defines a series of communication layers, including a transport layer and a network layer. At the transport layer, TCP/IP includes both the User Data Protocol (UDP), which is a connectionless transport protocol, and TCP which is a reliable, connection-oriented transport protocol. When a process at one network entity wishes to communicate with another entity, it formulates one or more messages and passes them to the upper layer of the TCP/IP communication stack. These messages are passed down through each layer of the stack where they are encapsulated into packets and frames. Each layer also adds information in the form of a header to the messages. The frames are then transmitted over the network links as bits. At the destination entity, the bits are reassembled and passed up the layers of the destination entity""s communication stack. At each layer, the corresponding message headers are also stripped off, thereby recovering the original message which is handed to the receiving process.
One or more intermediate network devices are often used to couple LANs together and allow the corresponding entities to exchange information. For example, a bridge may be used to provide a xe2x80x9cbridgingxe2x80x9d function between two or more LANs. Alternatively, a switch may be utilized to provide a xe2x80x9cswitchingxe2x80x9d function for transferring information, such as data frames or packets, among entities of a computer network. Typically, the switch is a computer having a plurality of ports that couple the switch to several LANs and to other switches. The switching function includes receiving data frames at a source port and transferring them to at least one destination port for receipt by another entity. Switches may operate at various levels of the communication stack. For example, a switch may operate at Layer 2 which, in the OSI Reference Model, is called the data link layer, and includes the Logical Link Control (LLC) and Media Access Control (MAC) sub-layers.
Other intermediate devices, commonly known as routers, may operate at higher communication layers, such as Layer 3, which in TCP/IP networks corresponds to the Internet Protocol (IP) layer. IP data packets include a corresponding header which contains an IP source address and an IP destination address. Routers or Layer 3 switches may re-assemble or convert received data frames from one LAN standard (e.g., Ethernet) to another (e.g., Token Ring). Thus, Layer 3 devices are often used to interconnect dissimilar subnetworks. Some Layer 3 intermediate network devices may also examine the transport layer headers of received messages to identify the corresponding TCP or UDP port numbers being utilized by the corresponding network entities. Many applications are assigned specific, fixed TCP and/or UDP port numbers in accordance with Request For Comments (RFC) 1700. For example, TCP/UDP port number 80 corresponds to the Hypertext Transport Protocol (HTTP), while port number 21 corresponds to File Transfer Protocol (FTP) service.
Computer networks include numerous services and resources for use in moving traffic throughout the network. For example, different network links, such as Fast Ethernet, Asynchronous Transfer Mode (ATM) channels, network tunnels, satellite links, etc., offer unique speed and bandwidth capabilities. Particular intermediate devices also include specific resources or services, such as number of priority queues, filter settings, availability of different queue selection strategies, congestion control algorithms, etc.
Individual frames or packets can be marked so that intermediate devices may treat them in a predetermined manner. For example, the Institute of Electrical and Electronics Engineers (IEEE) describes additional information for the MAC header of Data Link Layer frames in Appendix 802.1p to the 802.1D bridge standard.
FIG. 1A is a partial block diagram of a Data Link frame 100 that includes a MAC destination address (DA) field 102, a MAC source address (SA) field 104 and a data field 106. According to the 802.1Q standard, a user_priority field 108, among others, is inserted after the MAC SA field 104. The user_priority field 108 may be loaded with a predetermined value (e.g., 0-7) that is associated with a particular treatment, such as background, best effort, excellent effort, etc. Network devices, upon examining the user_priority field 108 of received Data Link frames 100, apply the corresponding treatment to the frames. For example, an intermediate device may have a plurality of transmission priority queues per port, and may assign frames to different queues of a destination port on the basis of the frame""s user priority value.
FIG. 1B is a partial block diagram of a Network Layer packet 120 corresponding to the Internet Protocol. Packet 120 includes a type_of_service (ToS) field 122, a protocol field 124, an IP source address (SA) field 126, an IP destination address (DA) field 128 and a data field 130. The ToS field 122 is used to specify a particular service to be applied to the packet 120, such as high reliability, fast delivery, accurate delivery, etc., and comprises a number of sub-fields. The sub-fields may include a 3-bit IP precedence (IPP) field and three one-bit flags that signify Delay, Throughput, and Reliability. By setting the flags, a device may indicate whether delay, throughput, or reliability is most important for the traffic associated with the packet. Version 6 of the Internet Protocol (Ipv6) defines a traffic class field, which is also intended to be used for defining the type of service to be applied to the associated packet.
A working group of the Internet Engineering Task Force (IETF) has proposed replacing the ToS field 122 of Network Layer packets 120 with a one-octet differentiated services (DS) field 132 that can be loaded with a differentiated services codepoint. Layer 3 devices that are DS compliant apply a particular per-hop forwarding behavior to data packets based on the contents of their DS fields 132. Examples of per-hop forwarding behaviors include expedited forwarding and assured forwarding. The DS field 132 is typically loaded by DS compliant intermediate devices located at the border of a DS domain, which is a set of DS compliant intermediate devices under common network administration. Thereafter, interior DS compliant devices along the path apply the corresponding forwarding behavior to the packet 120.
FIG. 1C is a partial block diagram of a Transport Layer packet 150 that preferably includes a source port field 152, a destination port field 154, and a data field 156, among others. Fields 152, 154 preferably are loaded with the TCP or UDP port numbers that are utilized by corresponding network entities.
To interconnect dispersed computer networks, many organizations rely on the infrastructure and facilities of Internet Service Providers (ISPs). For example, an organization may lease one or more T1 lines to interconnect various LANs. Each organization enters into a service-level agreement with its ISP. The service level agreements include one or more traffic specifications. The traffic specifications may place limits on the amount of resources that the organization may consume for a given price.
For example, an organization may agree not to send traffic that exceeds a certain bandwidth, e.g., 1 Mb/s. Traffic entering the service provider""s network is monitored to ensure that it complies with the relevant traffic specifications and is thus xe2x80x9cin profile.xe2x80x9d Traffic that exceeds a traffic specification, and is therefore xe2x80x9cout of profilexe2x80x9d may be dropped or shaped or may cause an accounting change. Alternatively, the service provider may mark the traffic as exceeding the traffic specification, but allow it to proceed through the network anyway. If there is congestion, an intermediate network device may drop such marked traffic first in an effort to relieve the congestion.
A process executing at a network entity may generate hundreds or thousands of traffic flows that are transmitted across a network. Generally, a traffic flow is a set of messages (frames and/or packets) that typically correspond to a particular task, transaction or operation (e.g., a print transaction) and may be identified by various network and transport parameters, such as source and destination IP addresses, source and destination TCP/UDP port numbers, and transport protocol.
The treatment that is applied to different traffic flows may vary depending on the particular traffic flow at issue. For example, an online trading application may generate stock quote messages, stock transaction messages, transaction status messages, corporate financial information messages, print messages, data backup messages, etc. A network administrator may wish to apply a different policy or service treatment (xe2x80x9cquality of servicexe2x80x9d or xe2x80x9cQoSxe2x80x9d) to each traffic flow. In particular, the network administrator may want a stock quote message to be given higher priority than a print transaction. Similarly, a $1 million stock transaction message for a premium client should be assigned higher priority than a $100 stock transaction message for a standard customer.
Currently, application programs that execute in network devices rarely invoke QoS functions, and therefore they do not take full advantage of QoS features that are available in the network devices.
Some intermediate network devices can distinguish among multiple traffic flows and can apply different QoS to the flows. Generally, QoS may be applied by such network devices based on the IP address or port number associated with a traffic flow. This approach has several advantages. It is centralized, it works with multiple applications, and it is application independent. However, there are also significant disadvantages. It is based on limited or no knowledge of application traffic flows. A network manager cannot define and apply QoS policies for individual applications. It has only limited applicability to encrypted packets.
In another known approach, applications use QoS signaling mechanisms, such as RSVP or differentiated services (xe2x80x9cDSxe2x80x9d or xe2x80x9cDiffServxe2x80x9d), to request a particular QoS for a particular traffic flow. In RSVP, a traffic flow passes a request for service that includes additional information to help a network device how to apply QoS. This approach can take advantage of detailed knowledge of different traffic flows produced by an application. However, there is no way to determine whether the RSVP requests comply with network-wide policies. The result is that the devices are often configured to ignore the signaling and treat all traffic equally.
Still another approach is IP precedence, in which a value is placed in a sub-field of the IP Type of Service field. This provides even less granular QoS control than DS.
Thus, current approaches do not adequately extend network device QoS features to multiple applications. These approaches do not integrate the application into the network and do not enable the application to classify its flows according to application-specific information. Further, there is no way to track applications that use dynamic port numbers, such as FTP.
Thus, there is a need for a mechanism that integrates applications into a policy-based networking system, and enables applications to participate in deciding how to apply a particular QoS to a traffic flow generated by the application.
Still another problem relates to how policies are defined. A typical business enterprise has separate individuals who are responsible for management of the enterprise""s network and for installation and maintenance of application programs that run in or use the network. These individuals normally have greatly differing areas of knowledge and expertise. The network manager generally knows the configuration of the network in intimate detail and knows, or can determine, which network devices support various QoS services. However, the network manager generally does not know details about traffic flows that are generated by the application programs. In contrast, the application manager typically has extensive knowledge about the application programs and the kinds of traffic they generate, but less knowledge about the network, its devices, and their QoS capabilities. Accordingly, there is a need for a way to create network QoS policies that incorporate these respective bodies of knowledge in an orderly and integrated manner.
Another problem in this field is storage and representation of policies that are used to determine QoS treatment of traffic flows. In past approaches, policies have been stored in an arbitrary manner, often outside the network, often in awkward and inconvenient form. For example, some network management policies exist only in mental form in the memories of network managers. Other policies are written but not stored in machine-usable form. As a result, QoS policies may conflict with other network management policies.
Recent work has begun to address some of these problems. For example, see J. Strassner, E. Ellesson, B. Moore, xe2x80x9cPolicy Framework Core Information Modelxe2x80x9d, draft-ietf-policy-core-info-model-00.txt; J. Strassner, E. Ellesson, B. Moore, xe2x80x9cPolicy Framework LDAP Core Schemaxe2x80x9d, draft-ietf-policy-core-schema-04.txt; J. Strassner, E. Ellesson, xe2x80x9cTerminology for describing network policy and servicesxe2x80x9d, draft-ietf-policy-terminology-02.txt. However, the schema described in this work must be extended to include QoS actions other then marking, shaping and policing. The schema includes only a basic set of variables and constants, and useful implementations must add their own.
There is an acute need for a mechanism or method with which policies may be represented using information structures that are accessible to and usable by other network elements.
The foregoing objects and advantages, and other objects and advantages that will become apparent from the following description, are achieved by the present invention, which comprises, in one embodiment, a method of integrating a network with policies representing quality of service treatments of network data flows for network devices. The method may comprise creating and storing information structures representing one or more of the policies representing quality of service treatments of network data flows for network devices according to a schema that is disclosed herein. The schema may be used to facilitate establishing QoS policies in network devices by creating and storing application information that associates one or more traffic flows generated by an application program, including information identifying one or more points at which an application generates the traffic flows; receiving device QoS information that defines one of more quality of service treatments that the network device may apply to data processed by the network device; based on the device QoS information and the application information, determining one or more processing policies that associate the traffic flows with the quality of service treatments; and creating and storing one or more mappings of the application information to the quality of service treatments that may be used to generate the quality of service value when the application program generates traffic flows.
In one feature, creating and storing information structures comprises creating and storing one or more policy trees, each policy tree comprising one or more policy domains and one or more repositories, each policy domain comprising one or more policy rules that reference one or more conditions and actions that are defined in the repositories and that represent one or more of the policies representing quality of service treatments of network data flows for network devices.
In another feature, creating and storing information structures comprises creating and storing one or more policy trees, each policy tree comprising one or more policy domains and one or more repositories, each policy domain comprising one or more policy rules that reference one or more conditions, actions and policers that are defined in the repositories and that represent one or more of the policies representing quality of service treatments of network data flows for network devices, and wherein each of the policers represents a flow limit on one or more of the network data flows.
In still another feature, creating and storing information structures comprises creating and storing one or more policy trees, each policy tree comprising one or more policy domains and one or more repositories, each policy domain comprising one or more policy rules that reference one or more conditions and actions that are defined in the repositories and that represent one or more of the policies representing quality of service treatments of network data flows for network devices; creating and storing one or more definitions of variables and constants in at least one of the repositories.
In yet another feature, creating and storing information structures comprises creating and storing one or more policy trees, each policy tree comprising one or more policy domains and one or more repositories, each policy domain comprising one or more policy rules that reference one or more conditions and actions that are defined in the repositories and that represent one or more of the policies representing quality of service treatments of network data flows for network devices; creating and storing one or more sub-policy objects associated with one of the policies in one of the policy domains, wherein each sub-policy object comprises at least one condition, action, and trigger.
Still another feature involves storing the mappings in a repository that is accessible by the application program; converting the mappings into one or more settings of the network device; and enforcing one of the processing policies at the network device in response to receiving traffic from the application program that matches the traffic flow type.
According to another feature, the method may involve creating and storing one or more classes that classify the traffic flows, each of the classes comprising one or more types of traffic flows; based on the device QoS information and the classes of the traffic flows, determining one or more processing policies that associate the traffic flows with the quality of service treatments. Another feature is that receiving application information comprises receiving one or more application code points that represent traffic flow types. Alternatively, receiving application information comprises receiving one or more differentiated services codes that represent traffic flow types.
In another feature, creating and storing one or more mappings comprises creating and storing one or more policies, concerning network processing of traffic flows generated by the application program, in the repository. Alternatively, creating and storing one or more mappings comprises creating and storing one or more policies, concerning network processing of traffic flows generated by the application program, in a policy store that is coupled to the repository. In still another alternative, creating and storing one or more mappings comprises creating and storing one or more policies, concerning network processing of traffic flows generated by the application program, in a directory. Yet another alternative is that creating and storing one or more mappings comprises creating and storing one or more policies, concerning network processing of traffic flows generated by the application program, in a policy server coupled to a Lightweight Directory Access Protocol directory that comprises the repository.
According to another feature, creating and storing one or more mappings further comprises creating and storing, in the repository, one or more mappings of Application Code Points of the application program to one or more Differential Services Code Points of a protocol associated with the network device. Further, creating and storing one or more mappings may comprise generating one or more messages in RSVP+ ( ) and communicating the messages to the network device.
In yet another feature, receiving application information comprises receiving application information that defines one or more traffic flows generated by an application program, including information identifying one or more points at which an application generates the traffic flows, from a first individual having responsibility for managing enterprise applications in the network. Further, receiving device QoS information may comprise receiving device QoS information that defines one of more quality of service treatments that the network device may apply to data processed by the network device, from a second individual having responsibility for managing the network.
In one embodiment, determining one or more processing policies comprises creating and storing one or more policy statements in a repository, wherein each policy statement associates a condition of one of the traffic flows, an operator, an operand, and an action comprising one of the quality of service treatments. Alternatively, determining one or more processing policies comprises creating and storing one or more policy statements in a repository, wherein each policy statement is represented by a plurality of nodes that represent a condition of one of the traffic flows, an operator, an operand, and an action comprising one of the quality of service treatments. In still another alternative, determining one or more processing policies comprises creating and storing one or more policy statements in a directory, wherein each policy statement is represented by a plurality of nodes that represent a condition of one of the traffic flows, an operator, an operand, and an action comprising one of the quality of service treatments, and wherein the plurality of nodes is coupled to a root node having a distinguished name in the directory.
Each of the mappings may comprise an application code point value stored in associated with a differentiated services code point value.
Enforcing one of the processing policies may comprise requesting an operating system function to modify a packet of the traffic flows using a policy element that requests a different operating system function according to the operating system then in use; at the network device, in response to receiving traffic from the application program that matches the traffic flow type and in response to the operating system function, modifying the packet to activate a quality of service treatment of the network device.
The present invention is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which like reference numerals refer to similar elements and in which:
FIG. 1A is a partial block diagram of a network message.
FIG. 1B is a partial block diagram of a network message.
FIG. 1C is a partial block diagram of a network message.
FIG. 2 is a simplified block diagram of a computer network.
FIG. 3 is a simplified partial block diagram of a local policy enforcer.
FIG. 4 is a block diagram of a process of determining application quality of service information.
FIG. 5A is a block diagram of a portion of a Repository that contains a Directory Schema.
FIG. 5B is a block diagram of a hierarchy of schemata.
FIG. 6A is a block diagram of a system that provides policy-based QoS treatment for application traffic flows.
FIG. 6B is a block diagram of the system of FIG. 6A showing structures relating to multi-platform support.
FIG. 7A is a flow diagram of steps of a configuration phase of operating the system of FIG. 6A and FIG. 6B.
FIG. 7B is a flow diagram of steps of an active phase of operating the system of FIG. 6A and FIG. 6B.
FIG. 8A is a block diagram of a containment hierarchy of a policy schema.
FIG. 8B is a block diagram of reusable object repositories.
FIG. 8C is a block diagram of information structures that may form a policy domain.
FIG. 8D is a block diagram of the structure of a policy rule.
FIG. 8E is a flow diagram of a method of processing policy information using a tree structured information model.
FIG. 9 is a block diagram of a computer system with which an embodiment may be carried out.